1. Field of the Invention
This invention relates to the monitoring of devices connected to a network. More particularly, it relates to a method, system, and computer program product for the remote monitoring of network-connected devices using multiple protocols.
2. Discussion of the Background
As is generally known, computer systems include hardware and software. Software includes a list of instructions that are created to operate and manage hardware components that make up a computer system. Typically, computer systems include a variety of hardware components/devices that interface with one another. The computer system can be a stand-alone type or a networked type. In a networked-type computer system, a plurality of distinct devices are connected to a network and thus communication between these distinct devices is enabled via the network.
Further, software for operating the hardware devices must be configured in order to allow communication between the hardware devices so that the hardware devices are enabled to function cooperatively. Further, in order to facilitate such a communication, it is also desirable for hardware devices to be monitored and the status of each hardware device identified in order to ensure that each hardware device is functioning in an efficient manner.
For the purposes of this patent application, the inventor has determined that a hardware device that is controlling, configuring, or monitoring the plurality of distinct devices or hardware devices would be referred to as a monitoring device and the hardware devices that are being controlled, configured, or monitored by the monitoring device would be referred to as “monitored devices.”
For hardware devices that are located on a network, it is desirable for these devices to be monitored for maintenance, usage, or other purposes. However, in view of manufacturer differences relating to hardware devices and interfaces, it may be difficult for a monitoring device to communicate with various other devices connected to a network. Such a disadvantage most likely prevents network administrators from obtaining crucial information about the performance and efficiency of the devices connected to the network.
The Simple Network Management Protocol (SNMP) is today a de-facto industry standard for the monitoring and management of devices on data communication networks, telecommunication systems and other globally reachable devices. Practically every organization dealing with computers and related devices expects to be able to centrally monitor, diagnose, and configure each such device across local- and wide-area networks. SNMP is the protocol that enables this interaction.
In order for a device to respond to SNMP requests, it is desirable to equip the device with the software that enables it to properly interpret an SNMP request, perform the actions required by that request, and produce an SNMP reply. The SNMP agent software is typically a subsystem software module residing in a network entity.
The collection of objects implemented by a system is generally referred to as a Management Information Base (MIB). An MIB may also be a database with information related to the monitoring of devices. Examples of other MIB's include Ethernet MIB, which focuses on Ethernet interfaces; Bridge MIB, which defines objects for the management of 802.ID bridges, to name a few.
Using SNMP for monitoring devices is difficult as private MIB's include values that are hard to decipher without a valid key. A company using SNMP for monitoring various devices connected to its network creates a unique identifier/key that is maintained as proprietary information of the company. For the most part, the results are displayed as binary or integer values. Thus, using SNMP, results received from the devices that are being monitored (“monitored devices”) fail to provide a user with the status of the monitored devices in a user comprehensible manner.
Further, using SNMP, it is difficult for one to obtain detailed information about a monitored device without a valid key or access to a private MIB to decipher the results obtained as binary or integer values. In addition, a given protocol (e.g., SNMP or HTTP/HTML) may fail for various reasons, such as time out or lost packets. Also, some information extracted from a given device using the multiple protocols may be duplicated for each protocol. Accordingly, if the extraction of data from the device is not properly managed in such situations, time and memory inefficiencies result since some protocols require more resources than other protocols. In addition, information extraction using some protocols may require much less processing and memory than using others. Furthermore, some information obtained through one protocol may be more useful for the monitoring device than the one obtained through another protocol.
In current monitoring systems, it is assumed that each protocol (e.g., SNMP, FTP, HTTP) used a single method corresponding to a single format to extract data from a monitored device. For example, the SNMP protocol gets the value corresponding to the Object identifier (OID) through the SNMP command GetNext. Moreover, the HTTP protocol using HTML gets the value using a Key Value, a position relative to the Key Value, and an In-line position relative to the delimiter. However, the present inventors have discovered that this assumption does not hold for the FTP protocol and for XML. For example, the data that should be extracted from a monitored device may be different depending upon the vendor and the particular FTP file. For XML, tags from various vendors may have different tag names.
FIGS. 38A-C show examples of the above problems with FTP files (samples 1-3). Samples 1-3 are examples of different files that can be obtained through the FTP protocol for devices from a particular vendor. Different methods are needed to extract information from each of these files. In the previous inventions, all the information for a given protocol is assumed to be in the same format. SNMP and HTTP/HTML follow the same method to extract the relevant information. However, just like FTP, it is possible that the different methods may be required to process HTTP/XML data because different manufacturers or different models of the same manufacturer may have different data structures for XML formatted data.
FIG. 38A shows an example FTP file containing information about the input trays, output trays, and printer languages of a network printer. A need exists for a monitoring system to extract information only from the lines containing information about each tray and each printer language. Such a system should determine what type of information is being extracted by looking for the text “Input Tray”, “Output Tray”, or “Printer Language”. After determining the type of information, the system should extract the status information following the column heading (i.e. dashed line). Each line following the column heading should be considered as a single piece of information until the end of the table is reached.
FIG. 38B shows an example FTP file containing information about a printer's print jobs. A monitoring system should consider the type of information in this file as a print job and should extract the status information following the column heading. Each line following the column heading should be considered as a single piece of information until the end of the table is reached. Unlike the FTP file of FIG. 38A, there is no need to determine the type of information since this FTP contains one type of information.
FIG. 38C shows an example FTP file containing information about a printer's system logs. A monitoring system should determine what information is being extracted by looking for the key text on each line (e.g. ncsd, inetd, snmpd, papserver, or any text between “[” and “(xx)]”). For each type of information, the system should treat the line corresponding to the key text as the status information for the type. In some cases, the status information for a type may extend over multiple lines such as the following lines of FIG. 38C show:                #[snmpd(23)]04/03/03 13:42:25 add_sess_ipx: bad trap addr: 00:00:00:00:00:00, community: RICOHTRAPS WARNING:In such case, the system should treat the two lines as the status information for the type snmpd. From the discussion of FIGS. 38A-C, there is an apparent need to process the FTP files differently to obtain status information from a monitored device.        